Skip to content

build/*.m4: Remove Bashisms/POSIX-ify the M4 helper macros #3359

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: v3/master
Choose a base branch
from

Conversation

BalkanMadman
Copy link

This commit makes it possible to build ModSecurity on systems where /bin/sh is a POSIX-compliant shell that is not Bash. Debian, Alpine Linux, and Gentoo Linux with the system shell set to not Bash, are examples of such systems.

Previously, the helper macros contained two types of Bashisms:

  • The == comparison operator. Very easy to change, as the proper POSIX-compliant form is =. For example:
if test "${var}" == "myvalue"  ->  if test "${var}" = "myvalue"
  • The '-a' (and) operator in the 'test' builtin. The '-a' and '-o' operators were removed in POSIX 2024 (Issue 8). The correct form is to use the '&&' and '||' operators respectively. For instance:
if test -d "${var}" -a -r "${var}/file"  ->  if test -d "${var}" && test -r "${var}/file"

Bug: https://bugs.gentoo.org/887135

what

  • The Bash == operator changed to the POSIX-compliant =.
  • The obsolete and removed in POSIX 2024 -a operator changed to the compliant &&.

why

  • Unable to build ModSecurity on systems where /bin/sh is not Bash (is dash, ash, etc.). See the Gentoo bug below.

references

This commit makes it possible to build ModSecurity on systems where
/bin/sh is a POSIX-compliant shell that is not Bash. Debian, Alpine
Linux, and Gentoo Linux with the system shell set to not Bash, are
examples of such systems.

Previously, the helper macros contained two types of Bashisms:

    * The '==' comparison operator. Very easy to change, as the proper
      POSIX-compliant form is '='. For example:

          if test "${var}" == "myvalue" -> if test "${var}" = "myvalue"

    * The '-a' (and) operator in the 'test' builtin. The '-a' and '-o'
      operators were removed in POSIX 2024 (Issue 8). The correct form
      is to use the '&&' and '||' operators respectively. For instance:

          if test -d "${var}" -a -r "${var}/file" ->
              if test -d "${var}" && test -r "${var}/file"

Bug: https://bugs.gentoo.org/887135
Signed-off-by: Zurab Kvachadze <[email protected]>
@@ -21,7 +21,7 @@ AC_ARG_WITH(
[test_paths="${with_pcre}"],
[test_paths="/usr/local/libpcre /usr/local/pcre /usr/local /opt/libpcre /opt/pcre /opt /usr /opt/local"])

if test "x${with_pcre}" == "x" && test "x${with_pcre}" != "xno"; then
if test "x${with_pcre}" = "x" && test "x${with_pcre}" != "xno"; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take a look at this comment from @theseion. I think he is right, and (unfortunately) we should review all complex conditions.

Moreover, I don't know: do we want to handle the yes value in case of all --with... options?

Here are the output of different scenarios (tested with these expressions):

if test "x${with_pcre}" = "x" && test "x${with_pcre}" != "xno"; then echo "TRUE"; else echo "FALSE";
if test "x${with_pcre}" = "x" || test "x${with_pcre}" != "xno"; then echo "TRUE"; else echo "FALSE";
Value of with_pcre expected output real output meanings
condition: &&
"" (empty) TRUE TRUE --with-pcre - we want to use PCRE
yes TRUE FALSE! --with-pcre=yes - we want to use PCRE
no FALSE FALSE --with-pcre=no - we do not want to use PCRE
condition: ||
"" (empty) TRUE TRUE --with-pcre - we want to use PCRE
yes TRUE TRUE --with-pcre=yes - we want to use PCRE
no FALSE FALSE --with-pcre=no - we do not want to use PCRE

@airween
Copy link
Member

airween commented May 11, 2025

Hi @BalkanMadman,

first of all, many thanks for this PR. I think this is a really important patch, we must apply this.

Please take a look at my comment above - I don't expect you to review all conditions, but that would be a huge help for the project.

Also, could you take a look at the v2/master tree too, and make this modifications?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants